1. Field of the Invention
The invention generally relates to systems for providing a secure processing environment. In particular, this invention relates to controllers used in card-enabled processing systems for providing secure access to data stored in data-carrying cards, including data received from smart cards, and for providing secure communications of processed data.
2. Description of the Related Art
Business, social, and government interactions in a technological society rely increasingly on electronically stored, processed, and accessed data. For example, data-carrying cards, such as "smart" cards having internal data processing capabilities, are used to store and process various types of data, like financial information, medical information, and welfare benefits information. Smart cards can store data relating to a transaction (e.g., a credit or a debit), eliminating the need for paper records. The use of such cards, however, raises several concerns.
One concern involves data security. Where data is sensitive or confidential, access to data stored on cards should be limited to those people with the appropriate authorization. Also, because data transmitted to and from cards can be easily duplicated or altered, data authentication is desirable to prevent fraudulent use of duplicated or altered data. To further prevent data manipulation and repudiation, data certification, which is a process of providing cryptographic proof of the origin and integrity of data, can be employed.
Another concern arises from the differences between smart cards' chip operating system (COS). Lack of clear industry standards in the smart card field results in incompatibilities between smart cards produced by different manufacturers. One manufacturer's smart card processing system often does not support another manufacturer's smart cards. This results in great inconvenience to smart card users, who are often unable to use their smart cards when they cannot locate systems capable of supporting their cards. Thus, there is a need for controllably bridging the incompatibilities of such systems. For example, if a user holds a debit card and wants to have his account debited immediately for a purchase, it would be desirable for any merchant who wants to make the sale to be able to accept and employ the user's debit card for that purpose, and to receive an immediate credit in his account. It would also be desirable for that merchant to be able to accept many other types of cards, such as credit cards and prepaid cards.
Despite the clarity of these needs, early attempts have proven to be inadequate. On the one hand, conventional systems have not provided adequate data security. A typical system aimed at providing a new service has a very limited environment and leaves an open end in terms of security. At present, one way that security is provided in smart cards systems is to implement security features as an integrated part of the systems' application. This tactic is inefficient and inherently dangerous--inefficient because of the effort associated with software development and the maintenance costs, and dangerous because application programmers still have access to the application program that provides the system security.
On the other hand, the broad-based usability that is desired for particular applications still eludes most of the likely users because of system differences large and small. Card-based systems from telephone to general credit to banking systems cannot accept cards not intended for the respective system, even when it would be to the economic advantage of the relevant business to do so. And despite the long-term need of the financial communities for a broad-based debit card, such a card and its touted advantage of a "cashless society" appears to be receding into the future. This state of events has occurred despite the proliferation of credit as a way of life and the proliferation of insertable cards as both data carriers and as "smart cards," cards which both carry data and perform some on-card processing of the data.
All of the foregoing problems have led to an over-arching need, particularly felt in the business community, to address security and the incompatibility of systems concurrently, and preferably as simply as possible. The need also extends beyond the business community, for example, to government. Even though the problems in the government area differ in detail, the same problems of security and incompatibility of systems are demanding attention.